home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxxx_8.lha / rfc1729 < prev    next >
Text File  |  1995-07-26  |  21KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           C. Lynch
  8. Request for Comments: 1729                      University of California
  9. Category: Informational                          Office of the President
  10.                                                            December 1994
  11.  
  12.  
  13.             Using the Z39.50 Information Retrieval Protocol
  14.                       in the Internet Environment
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Summary
  23.  
  24.    This memo describes an approach to the implementation of the
  25.    ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the
  26.    TCP/IP environment which is currently in wide use by the Z39.50
  27.    implementor community.
  28.  
  29. Introduction
  30.  
  31.    Z39.50 is a US national standard defining a protocol for computer-
  32.    to-computer information retrieval that was first adopted in 1988 [1]
  33.    and extensively revised in 1992 [2]. It was developed by the National
  34.    Information Standards Organization (NISO), an ANSI-accredited
  35.    standards development body that serves the publishing, library, and
  36.    information services communities. The closely related international
  37.    standard, ISO 10162 (service definition) [3] and 10163 (protocol)
  38.    [4], colloquially known as Search and Retrieve or SR, reached full
  39.    International Standard (IS) status in 1991. Work is ongoing within
  40.    ISO Technical Committee 46 Working Group 4 Subgroup 4 to progress
  41.    various extensions to SR through the international standards process.
  42.    The international standard is essentially a compatible subset of the
  43.    current US Z39.50-1992 standard. Z39.50 is an applications layer
  44.    protocol within the OSI reference model, which assumes the presence
  45.    of lower-level OSI services (in particular, the presentation layer
  46.    [5]) and of the OSI Association Control Service Element (ACSE) [6]
  47.    within the application layer.
  48.  
  49.    Many institutions implementing this protocol chose, for various
  50.    reasons, to layer the protocol directly over TCP/IP rather than to
  51.    implement it in an OSI environment or to use the existing techniques
  52.    that provide full OSI services at and above the OSI Transport layer
  53.    on top of TCP connections (as defined in RFC 1006 [7] and
  54.    implemented, for example, in the ISO Development Environment
  55.  
  56.  
  57.  
  58. Lynch                                                           [Page 1]
  59.  
  60. RFC 1729      Using the Z39.50 in the Internet Environment December 1994
  61.  
  62.  
  63.    software). These reasons included concerns about the size and
  64.    complexity of OSI implementations, the lack of availability of mature
  65.    OSI software for the full range of computing environments in use at
  66.    these institutions, and the perception of relative instability of the
  67.    architectural structures within the OSI applications layer (as
  68.    opposed to specific application layer protocols such as Z39.50
  69.    itself). Most importantly, some of these institutions were concerned
  70.    that the complexity introduced by the OSI upper layers would outweigh
  71.    the relatively meager return in functionality that they were likely
  72.    to gain. Thus, for better or worse, the decision was taken to
  73.    implement the Z39.50 protocol directly on top of TCP (with the
  74.    understanding that this decision might be revisited at some point in
  75.    the future).
  76.  
  77.    During 1991-1993, a group of implementing institutions agreed to
  78.    participate in the Z39.50 Interoperability Testbed project (sometimes
  79.    referred to by the acronym "ZIT") under the auspices of the Coalition
  80.    for Networked Information (CNI). Their primary objective was to
  81.    encourage the development of many interoperable Z39.50
  82.    implementations running over TCP/IP on the Internet. By mid-1993, a
  83.    number of independent Z39.50 implementations were operational and
  84.    able to interoperate across the Internet.
  85.  
  86.    The Library of Congress, in its role as the Z39.50 Maintenance Agency
  87.    for NISO, maintains a registry of the implementors [8], which
  88.    includes members of the Z39.50 interoperability testbed.
  89.  
  90.    This document describes implementation decisions by current
  91.    implementors of Z39.50 in the Internet environment. These have been
  92.    proven within the ZIT project and are being used by most of the
  93.    members of the Z39.50 Implementors' Group (ZIG), an informal group
  94.    that meets quarterly to discuss implementation and interoperability
  95.    issues and to develop extensions to the Z39.50 protocol targeted for
  96.    inclusion in future versions of the standard. Intended as a guide for
  97.    other implementors who seek to develop interoperable Z39.50
  98.    implementations running over TCP/IP, this document focuses on issues
  99.    related to TCP/IP, and it does not address other potential
  100.    interoperability problems or agreements that have been reached among
  101.    the implementors to address these problems. It does include a few
  102.    notes about extensions to the existing Version 2 protocol that are
  103.    being used in the implementor community which have interoperability
  104.    implications.  Potential implementors of Z39.50 should subscribe to
  105.    the Z3950IW LISTSERV [9] to obtain information specific to the Z39.50
  106.    protocol and extensions under development as well as details of
  107.    current implementations.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Lynch                                                           [Page 2]
  115.  
  116. RFC 1729      Using the Z39.50 in the Internet Environment December 1994
  117.  
  118.  
  119.    Except where otherwise noted, the version of Z39.50 discussed here is
  120.    ANSI/NISO Z39.50-1992, sometimes called Z39.50 Version 2 (the
  121.    obsolete original version is referred to as Z39.50-1988 or Z39.50
  122.    Version 1). The approach defined should also be applicable, perhaps
  123.    with some minor changes, to future versions of the Z39.50 protocol,
  124.    and specifically to Version 3 which is currently under development.
  125.    This document will probably be updated to address new versions of the
  126.    base Z39.50 protocol as they become stable.
  127.  
  128. Encoding
  129.  
  130.    The Z39.50 standard specifies its application protocol data units
  131.    (APDUs) in Abstract Syntax Notation One (ASN.1) [10]. These APDUs
  132.    include EXTERNAL references to other ASN.1 and non-ASN.1 objects such
  133.    as those defining record transfer syntaxes to be used in a given
  134.    application association.
  135.  
  136.    The standard Basic Encoding Rules (BER) [11] are applied to the ASN.1
  137.    structures defined by the Z39.50 protocol to produce a byte stream
  138.    that can be transmitted across a TCP/IP connection. The only
  139.    restriction on the use of BER to produce this byte stream is that
  140.    direct, rather than indirect, references must be used for EXTERNAL
  141.    objects. This is necessary because there is no presentation context
  142.    in the TCP/IP environment to support indirect reference. A Z39.50
  143.    implementation developed according to this specification and running
  144.    over TCP/IP should produce a valid byte stream according to the
  145.    Z39.50 standard, in the sense that the same byte stream could be
  146.    passed to an OSI implementation. However, not all byte streams that
  147.    can be produced by applying BER to the APDUs specified in the Z39.50
  148.    standard in an OSI environment will be legitimate under this
  149.    specification for the TCP/IP environment; this specification defines
  150.    a subset of the possible byte streams valid in a pure OSI environment
  151.    which excludes those using indirect reference for EXTERNAL objects.
  152.  
  153.    All other BER features should be tolerated by Z39.50 implementations
  154.    running over TCP/IP, including the ability to accept indefinite
  155.    length encodings, although it is preferable that implementations do
  156.    not generate such encodings since they have caused problems for some
  157.    ASN.1/BER parsers.  It should also be noted that at least to the best
  158.    of the author's knowledge, there are no implementations at present
  159.    that use ASN.1/BER representations of floating point numbers;
  160.    instead, integers with scaling factors have been used for these
  161.    purposes. It should also be noted that Z39.50 version 2 does not
  162.    really address character set encoding issues; these questions, and
  163.    their interactions with ASN.1/BER support for multiple character
  164.    sets, are under active discussion as part of the effort to develop
  165.    Z39.50 version 3.
  166.  
  167.  
  168.  
  169.  
  170. Lynch                                                           [Page 3]
  171.  
  172. RFC 1729      Using the Z39.50 in the Internet Environment December 1994
  173.  
  174.  
  175. Connection
  176.  
  177.    In the Internet environment, TCP Port 210 has been assigned to Z39.50
  178.    by the Internet Assigned Numbers Authority [12]. To initiate a Z39.50
  179.    connection to a server in the TCP/IP environment, a client simply
  180.    opens a TCP connection to port 210 on the server and then, as soon as
  181.    the TCP connection is established, transmits a Z39.50 INIT APDU using
  182.    the BER encoding of that INIT APDU as described above.
  183.  
  184.    Implementors should be aware that there is a substantial installed
  185.    base of implementations of the Wide Area Information Server (WAIS)
  186.    system. The original versions of this software employed Z39.50
  187.    Version 1 with some extensions. Z39.50 Version 1 did not use BER
  188.    encoding and Z39.50 Version 1 INIT APDUs look very different from the
  189.    INIT APDUs of Z39.50 Version 2.  Implementations of Z39.50 should at
  190.    least be prepared to reject gracefully WAIS-type INIT APDUs. Some
  191.    implementations recognize such INIT APDUs and revert to the Z39.50
  192.    Version 1 variant used in WAIS upon encountering them, thus providing
  193.    backwards compatibility with the existing base of WAIS clients and;
  194.    the usual means of checking for a WAIS, as opposed to Z39.50 Version
  195.    2, client is to see if the first byte sent on the connection is an
  196.    ASCII zero, which indicates a WAIS client. (In version 1 of WAIS,
  197.    bytes 0-9 of the first PDU contain an ASCII packet length; the lower
  198.    case ASCII string "wais" appears starting at byte 12.) Work is
  199.    currently underway to specify a WAIS profile for use with Z39.50
  200.    version 2 [13]; it is expected that this will be issued as a Z39.50
  201.    Applications Profile through the NIST OIW Library Automation Special
  202.    Interest Group. This profile is expected to be compatible with the
  203.    layering defined in this RFC.
  204.  
  205. Service Mappings
  206.  
  207.    The Z39.50 standard maps Z39.50 services onto a variety of
  208.    association control and presentation layer services. Connection
  209.    establishment has already been discussed. The other two association
  210.    control services that are relevant to Z39.50 are ABORT and RELEASE.
  211.    The mapping of the RELEASE service to a standard TCP CLOSE is
  212.    straightforward. The Z39.50 protocol itself does not, in the current
  213.    version, include a Z39.50 CLOSE APDU. When the client has completed
  214.    its interaction with the server, it calls the IR-RELEASE service,
  215.    which is directly mapped to association control's orderly association
  216.    release. In the TCP/IP environment, the client should simply initiate
  217.    a TCP CLOSE. The mapping for association abort is more complex,
  218.    partially because some TCP/IP implementations cannot distinguish a
  219.    TCP reset from the other side of the connection from other events. To
  220.    accomplish an abort (that is, a mapping of the IR-ABORT service in
  221.    the Z39.50 protocol) in the TCP/IP environment, client or server need
  222.    only terminate the TCP connection either via TCP ABORT or TCP CLOSE.
  223.  
  224.  
  225.  
  226. Lynch                                                           [Page 4]
  227.  
  228. RFC 1729      Using the Z39.50 in the Internet Environment December 1994
  229.  
  230.  
  231.    Real-world implementations need to be prepared to deal with both TCP
  232.    ABORT and CLOSE anyway, so this approach presents no additional
  233.    problems, other than the somewhat ambiguous nature of the type of
  234.    association termination.
  235.  
  236.    It is expected that Z39.50 Version 3 will include a termination
  237.    service which will involve an exchange of Z39.50 CLOSE APDUs,
  238.    followed by an association RELEASE (which would presumably, in the
  239.    Internet environment, be mapped to a TCP CLOSE). This new termination
  240.    service is expected to support both graceful and abrupt termination.
  241.    Of course, robust implementations will still need to be prepared to
  242.    encounter TCP CLOSE or ABORT.
  243.  
  244.    Service mappings for the transmission of data by client and server
  245.    (to the presentation layer P-DATA service) are trivial: They are
  246.    simply mapped to TCP transmit and receive operations. TCP facilities
  247.    such as expedited data are not used by Z39.50 in a TCP environment.
  248.  
  249. Contexts
  250.  
  251.    At the point when the TCP connection is established on TCP port 210,
  252.    client and server should both assume that the application context
  253.    given in Appendices A and B of the Z39.50-1992 standard are in place.
  254.    These are the ASN.1 definitions of the Z39.50 APDUs and the transfer
  255.    syntax defined by applying the BER to these APDUs.
  256.  
  257.    Implementations can reasonably expect that the diagnostic set BIB-1
  258.    is supported, and, if resource control is being used, the resource
  259.    report format BIB-1 is supported as well.
  260.  
  261.    In the absence of a presentation negotiation mechanism, clients and
  262.    servers should be cautious about using alternative attribute sets,
  263.    diagnostic record formats, resource report formats, or other objects
  264.    defined by optional EXTERNALs within the Z39.50 ASN.1, such as
  265.    authentication parameters, unless there is known to be prior
  266.    agreement to support them. Of course, either participant in an
  267.    association can reference such an object by object ID in an APDU, but
  268.    there is no guarantee that the other partner in the association will
  269.    be able to understand it. Robust implementations should be prepared
  270.    to encounter unknown or unsupported object IDs and generate
  271.    appropriate diagnostics. Over time, the default, commonly known pool
  272.    of object IDs may be expanded (for example, to support authentication
  273.    parameters).
  274.  
  275.    Implementors should refer to the document [14] issued by the Z39.50
  276.    maintenance agency in June 1992 for more details on the assumed
  277.    contexts and object identifiers.
  278.  
  279.  
  280.  
  281.  
  282. Lynch                                                           [Page 5]
  283.  
  284. RFC 1729      Using the Z39.50 in the Internet Environment December 1994
  285.  
  286.  
  287.    Record syntaxes present a serious practical problem. In the OSI
  288.    environment, the partners in a Z39.50 association are assumed to
  289.    agree, either through presentation negotiation as part of association
  290.    establishment, or later, dynamically, as part of the PRESENT process
  291.    (through the use of the alter presentation context function at the
  292.    presentation layer), on which record syntaxes the two entities
  293.    commonly know. There is a preferred record syntax parameter that can
  294.    be supplied by the client to guide this negotiation. A number of
  295.    registered record syntaxes exist; some are based on ASN.1 and others
  296.    use formats such as the MARC standard for the interchange of machine
  297.    readable cataloging records which predate ASN.1, but are widely
  298.    implemented.  In the TCP/IP environment, if the server cannot supply
  299.    the record in the preferred syntax, it has no guarantee that the
  300.    client will understand any other syntax in which it might transmit
  301.    the record back to the client, and has no means of negotiating such
  302.    syntaxes.
  303.  
  304.    Several proposals have been suggested to solve this problem. One,
  305.    which will likely be part of Z39.50 Version 3, is to replace the
  306.    preferred record syntax parameter with a list of prioritized
  307.    preferred syntaxes supplied by the client, plus a flag indicating
  308.    whether the server is allowed to substitute a record syntax not on
  309.    the list provided by the client. The currently proposed ASN.1 for
  310.    this extension is upwards compatible with Z39.50 Version 2, although
  311.    the details are still under discussion within the Z39.50
  312.    Implementor's Group. As the Version 3 ASN.1 becomes stable in this
  313.    area, Z39.50 servers are encouraged to accept the extended ASN.1 for
  314.    generalized preferred record syntax. The extensibility rules for
  315.    Z39.50 negotiation let clients and servers negotiate the use of
  316.    Z39.50 Version 2 plus the generalized preferred syntax feature from
  317.    Version 3. Thus, a client could support the generalized preferred
  318.    record syntax, propose its use to any server, and, if the server
  319.    rejects the proposal, revert to the Version 2 preferred syntax
  320.    feature.
  321.  
  322.    A second alternative (not incompatible with the Version 3 extension)
  323.    would be to adopt a convention for TCP/IP implementations that the
  324.    server not return a record in a syntax not on the preferred record
  325.    syntax list provided by the client. Instead, it would return a
  326.    diagnostic record indicating that a suitable record transfer syntax
  327.    was not available. This strategy could be viewed as simply
  328.    implementing a subset of the Version 3 solution, and should be
  329.    considered by implementors of servers as a possible interim measure.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Lynch                                                           [Page 6]
  339.  
  340. RFC 1729      Using the Z39.50 in the Internet Environment December 1994
  341.  
  342.  
  343. Other Interoperability Issues
  344.  
  345.    Version 3 will include an "other" data field in each APDU, which can
  346.    be used to carry implementation-specific extensions to the protocol.
  347.    A number of implementations are already employing this field, and
  348.    interoperable implementations might be wise to include code which at
  349.    least ignores the presence of such fields rather than considering
  350.    their presence an error (in contravention of the standard).
  351.  
  352. References
  353.  
  354.    [1] National Information Standards Organization (NISO). American
  355.        National Standard Z39.50, Information Retrieval Service
  356.        Definition and Protocol Specifications for Library Applications
  357.        (New Brunswick, NJ: Transaction Publishers; 1988).
  358.  
  359.    [2] ANSI/NISO Z39.50-1992 (version 2) Information Retrieval Service
  360.        and Protocol: American National Standard, Information Retrieval
  361.        Application Service Definition and Protocol Specification for
  362.        Open Systems Interconnection, 1992.
  363.  
  364.    [3] ISO 10162 International Organization for Standardization (ISO).
  365.        Documentation -- Search and Retrieve Service Definition, 1992.
  366.  
  367.    [4] ISO 10163 International Organization for Standardization (ISO).
  368.        Documentation -- Search and Retrieve Protocol Definition. 1992.
  369.  
  370.    [5] ISO 8822 - Information Processing Systems - Open Systems
  371.        Interconnection - Connection Oriented Presentation Service
  372.        Definition, 1988.
  373.  
  374.    [6] ISO 8649 - Information Processing Systems - Open Systems
  375.        Interconnection - Service Definition for the Association Control
  376.        Service Element, 1987. See also ISO 8650 - Information Processing
  377.        Systems - Open Systems Interconnection - Protocol Specification
  378.        for the Association Control Service Element, 1987.
  379.  
  380.    [7] Rose, M., and D. Cass, "ISO Transport Layer Services on Top of
  381.        the TCP, Version 3", STD 35, RFC 1006, Northrop Research and
  382.        Technology Center, May 1987.
  383.  
  384.    [8] Registry of Z39.50 Implementors, available from the Z39.50
  385.        Maintenance Agency (Ray Denenberg, ray@rden.loc.gov)
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Lynch                                                           [Page 7]
  395.  
  396. RFC 1729      Using the Z39.50 in the Internet Environment December 1994
  397.  
  398.  
  399.    [9] To subscribe to the Z39.50 Implementor's Workshop list send the
  400.        message: SUB Z3950IW yourname to: LISTSERV@NERVM.NERDC.UFL.EDU
  401.        (or NERVM.BITNET).  Current drafts of the Version 3 Protocol
  402.        document are available through the Library of Congress GOPHER
  403.        server, MARVEL.LOC.GOV.
  404.  
  405.   [10] ISO 8824 - Information Processing Systems - Open Systems
  406.        Interconnection - Specifications for Abstract Syntax Notation One
  407.        (ASN.1), 1987
  408.  
  409.   [11] ISO 8825 Information Processing Systems - Open Systems
  410.        Interconnection - Specification of Basic Encoding Rules for
  411.        Abstract Syntax Notation One (ASN.1) 1987
  412.  
  413.   [12] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  414.        USC/Information Sciences Institute, October 1994.
  415.  
  416.   [13] WAIS Profile of Z39.50 Version 2, Revision 1.4, April 26, 1994,
  417.        available from WAIS Inc.
  418.  
  419.   [14] Registration of Z39.50 OSI Object Identifiers (Z39.50-MA-024),
  420.        available from the Z39.50 Maintenance Agency (Ray Denenberg,
  421.        ray@rden.loc.gov).
  422.  
  423. Security Considerations
  424.  
  425.    This document does not discuss security considerations. However, it
  426.    should be noted that the Z39.50 protocol includes mechanisms for
  427.    authentication and security that implementors should review.
  428.  
  429. Author's Address
  430.  
  431.    Clifford A. Lynch
  432.    University of California, Office of the President
  433.    300 Lakeside Drive, 8th Floor
  434.    Oakland, CA 94612-3550
  435.  
  436.    Phone: (510) 987-0522
  437.    EMail: clifford.lynch@ucop.edu
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Lynch                                                           [Page 8]
  451.  
  452.